<!DOCTYPE html>
<html>

  <head>
    <meta charset='utf-8' />
    <meta http-equiv="X-UA-Compatible" content="chrome=1" />
    <meta name="description" content="CAS - Single Sign-On for the Web" />
    
    
    <link rel="stylesheet" type="text/css" media="screen"
          href="../../stylesheets/v40x-stylesheet.css">
    <link rel="stylesheet" type="text/css" media="print"
          href="../../stylesheets/print.css">
    <title>CAS - Security Guide</title>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
    <script src="../../javascripts/URI.js"></script>
    <script src="../../javascripts/v40x-main.js"></script>
  </head>

  <body>
    <!-- HEADER -->
    <div id="header_wrap" class="outer">
        <header class="inner">
          <a id="forkme_banner" href="https://github.com/Jasig/cas">View on GitHub</a>
          <div id="project_title">
            <a class="undecorated" href="../../index.html">
              <img class="undecorated" src="../../images/cas_logo.png"/>
            </a>
          </div>
          <h2 id="project_tagline">Single Sign-On for the Web</h2>
        </header>
    </div>

    <!-- NAVBAR -->    
    <div id="navbar_wrap" class="outer">
      <header id="navbar_content" class="inner">
        <div class="navlink">
  <a href="../../index.html">Home</a>
</div>
<div class="navlink">
  <a href="https://github.com/Jasig/cas/releases">Downloads</a>
</div>
<div class="navlink">
  <a href="https://www.google.com/cse/publicurl?cx=017040929083740828958:sqr2hwvrxmg">Search</a>
</div>
<div class="navlink">
  <a href="../../Support.html">Support</a>
</div>
<div class="navlink">
  <a href="../../Mailing-Lists.html">Mailing Lists</a>
</div>
<div class="navlink">
  <a href="../../Older-Versions.html">Older Versions</a>
</div>

        </header>
    </div>

      <!-- SIDEBAR -->
      <div id="sidebar_wrap" class="outer">
        <header id="sidebar_content" class="inner">
          <span id="sidebartoc"></span>
        </header >
      </div>
      
      <!-- PAGE TABLE OF CONTENTS -->
      <div id="table_contents" class="outer">
        <header id="sidebar_content" class="inner">
          <span id="tableOfContents"></span>
        </header>
      </div>
      
      <!-- MAIN CONTENT -->
      <div id="main_content_wrap" class="outer">
        <section id="main_content" class="inner">
          <h1 id="security-guide">Security Guide</h1>
<p>CAS is security software that provides secure Web-based single sign-on to Web-based applications. Single sign-on
provides a win/win in terms of security and convenience: it reduces password exposure to a single, trusted credential
broker while transparently providing access to multiple services without repetitious logins. The use of CAS generally
improves the security environment, but there are several CAS configuration, policy, and deployment concerns that should
be considered to achieve suitable security.</p>

<h2 id="system-security-considerations">System Security Considerations</h2>

<h3 id="secure-transport-https">Secure Transport (https)</h3>
<p>All communication with the CAS server MUST occur over a secure channel (i.e. SSLv3, TLSv1). There are two primary
justifications for this requirement:</p>

<ol>
  <li>The authentication process requires transmission of security credentials.</li>
  <li>The CAS ticket-granting ticket is a bearer token.</li>
</ol>

<p>Since the disclosure of either data would allow impersonation attacks, it’s vitally important to secure the
communication channel between CAS clients and the CAS server.</p>

<p>Practically, it means that all CAS urls must use HTTPS, but it <strong>also</strong> means that all connections from the CAS server to the application must be done using HTTPS:
- when the generated service ticket is sent back to the application on the “service” url
- when a proxy callback url is called.</p>

<h3 id="connections-to-dependent-systems">Connections to Dependent Systems</h3>
<p>CAS commonly requires connections to other systems such as LDAP directories, databases, and caching services.
We generally recommend to use secure transport (SSL/TLS, IPSec) to those systems where possible, but there may
be compensating controls that make secure transport uncessary. Private networks and corporate networks with strict
acces controls are common exceptions, but secure transport is recommended nonetheless.
Client certification validation can be another good solution for LDAP to bring sufficient security.</p>

<p>As stated previously, connections to other systems must be secured. But if the CAS server is deployed on several nodes, the same applies to the CAS server itself:
if an EhCache tickets registry runs without any security issue on a single CAS server, synchronization can become a security problem when using multiple nodes if the network is not protected.</p>

<p>Any disk storage is also vulnerable if not properly secured. EhCache overflow to disk may be turned off to increase protection whereas advanced encryption data mechanism should be used for the database disk storage.</p>

<h2 id="deployment-driven-security-features">Deployment-Driven Security Features</h2>
<p>CAS supports a number of features that can be leveraged to implement various security policies.
The following features are provided through CAS configuration and CAS client integration. Note that many features
are available out of the box, while others require explicit setup.</p>

<h3 id="forced-authentication">Forced Authentication</h3>
<p>Many CAS clients and supported protocols support the concept of forced authentication whereby a user must
reauthenticate to access a particular service. The CAS protocols support forced authentication via the <em>renew</em>
parameter. Forced authentication provides additional assurance in the identity of
the principal of an SSO session since the user must verify his or her credentials prior to access.
Forced authentication is suitable for services where higher security is desired or mandated. Typically forced
authentication is configured on a per-service basis, but the <a href="#service_management">service management</a> facility
provides some support for implementing forced authentication as a matter of centralized security policy.
Forced authentication may be combined with <a href="#multifactor_authentication">multi-factor authentication</a> features to
implement arbitrary service-specific access control policy.</p>

<h3 id="passive-authentication">Passive Authentication</h3>
<p>Some CAS protocols support passive authentication where access to a CAS-protected service is granted anonymously
when requested. The CASv2 and CASv3 protocols support this capability via the <em>gateway</em> feature. Passive authentication
complements forced authentication; where forced authentication requires authentication to access a service, passive
authentication permits service access, albeit anonymously, without authentication.</p>

<h3 id="proxy-authentication">Proxy Authentication</h3>
<p>Proxy authentication, or delegated authentication, provides a powerful, important, and potentially security-improving
feature of CAS. Proxy authentication is supported by the CASv2 and CASv3 protocols and is mediated by proxy tickets
that are requested by a service on behalf of a user; thus the service proxies authentication for the user.
Proxy authentication is commonly used in cases where a service cannot interact directly with the user and as an
alternative to replaying end-user credentials to a service.</p>

<p>However, proxy tickets carry risk in that services accepting proxy tickets are responsible for validating the
proxy chain (the list of services through which the end-user’s authentication have been delegated to arrive at
the ticket validating service). Services can opt out of accepting proxy tickets entirely (and avoid
responsibility for validating proxy chains) by simply validating tickets against the /serviceValidate
validation endpoint, but experience has shown it’s easy to be confused about this and configure to
unintentionally use the /proxyValidate endpoint yet not scrutinize any proxy chains that appear in the
ticket validation response. Thus proxy authentication requires careful configuration for proper security controls;
it is recommended to disable proxy authentication components at the CAS server if proxy authentication is not
needed.</p>

<p>Historically any service could obtain a proxy-granting ticket and from it a proxy ticket to access any other service.
In other words, the security model is decentralized rather than centralized. The service management facility affords
some centralized control of proxy authentication by exposing a proxy authentication flag that can enabled or disabled
on a per-service basis. By default registered services are not granted proxy authentication capability.</p>

<h3 id="multi-factor-authentication">Multi-factor Authentication</h3>
<p>CAS 4 provides support for multi-factor authentication in one of two modes: global and per-service. The global case
where multiple credentials are invariably required on the login form is straightforward: the user interface is
modified to accept multiple credentials and authentication components are configured to require successful
authentication of all provided credentials.</p>

<p>The per-service case is both more interesting and more complicated:</p>

<ul>
  <li>Levels of identity assurance (LOA) for credentials and groups of credentials must be established.</li>
  <li>Security policy versus credential LOA must be established per service.</li>
  <li>Service access policy must be configured via the <a href="#service_management">service management</a> facility.</li>
</ul>

<p>The first two tasks are vital but outside the scope of this document. Application of service access policy via the
service management facility is implemented by declaring the
<a href="../installation/Configuring-Authentication-Components.html#authentication_handlers">authentication handlers</a>
that must successfully authenticate credentials in order to permit access; for example, an LDAP authentication
handler and an RSA SecureID authentication handler.</p>

<p>Since multi-factor authentication requires development of institutional security policy, advanced component
configuration (and possibly custom component development), and UI design, it should be regarded more as a framework
than a feature. See the
<a href="../installation/Configuring-Authentication-Components.html#multifactor_authentication_mfa">multi-factor configuration</a>
section for detailed discussion of configuration concerns and implementation recommendations.</p>

<h3 id="credential-caching-and-replay">Credential Caching and Replay</h3>
<p>The <em>ClearPass</em> extension provides a mechanism to capture primary authentication credentials, cache them (encrypted),
and replay on demand as needed to access legacy services. While <a href="#proxy_authentication">proxy authentication</a>
is recommended in lieu of password replay, it may be required to integrate legacy services with CAS. See the
<a href="../integration/ClearPass.html">ClearPass</a> documentation for detailed information.</p>

<h3 id="service-management">Service Management</h3>
<p>The service management facility provides a number of service-specific configuration controls that affect security
policy and provide some support for centralized security policy. (Note that CAS has historically supported the
decentralized security policy model.) Some highlights of service management controls:</p>

<ul>
  <li>Authorized services</li>
  <li>Forced authentication</li>
  <li>Attribute release</li>
  <li>Proxy authentication control</li>
  <li>Theme control</li>
  <li>Multi-factor service access policy</li>
</ul>

<p>The service management facility is comprised of a service registry containing one or more registered services, each
of which specifies the management controls above. The service registry can be controlled via static configuration files,
a Web user interface, or both. See the <a href="../installation/Service-Management.html">Service Management</a> section for more
information.</p>

<h3 id="ticket-expiration-policies">Ticket Expiration Policies</h3>
<p>Ticket expiration policies are a primary mechanism for implementing security policy. Ticket expiration policy allows
control of some important aspects of CAS SSO session behavior:</p>

<ul>
  <li>SSO session duration (sliding expiration, absolute)</li>
  <li>Ticket reuse</li>
</ul>

<p>See the <a href="../installation/Configuring-Ticketing-Components.html">Configuring Ticketing Components</a> section for a
detailed discussion of the various expiration policies and configuration instructions.</p>

<h3 id="single-sign-out">Single Sign-Out</h3>
<p>Single sign-out, or single log-out (SLO), is a feature by which CAS services are notified of the termination of a CAS
SSO session with the expectation that services terminate access for the SSO session owner. While single sign-out can
improve security, it is fundamentally a best-effort facility and may not actually terminate access to all services
consumed during an SSO session. The following compensating controls may be used to improve risks associated with
single sign-out shortcomings:</p>

<ul>
  <li>Require forced authentication for sensitive services</li>
  <li>Reduce application session timeouts</li>
  <li>Reduce SSO session duration</li>
</ul>

<h3 id="login-throttling">Login Throttling</h3>
<p>CAS supports a policy-driven feature to limit successive failed authentication attempts to help prevent brute force
and denial of service attacks. The feature is beneficial in environments where back-end authentication stores lack
equivalent features. In cases where this support is available in underlying systems, we encourage using it instead
of CAS features; the justification is that enabling support in underlying systems provides the feature in all dependant
systems including CAS. See the
<a href="../installation/Configuring-Authentication-Components.html#login_throttling">login throttling configuration</a>
section for further information.</p>

<h3 id="credential-encryption">Credential Encryption</h3>
<p>An open source product called <a href="http://www.jasypt.org/cli.html">Java Simplified Encryption</a>  allows you to replace clear text passwords in files with encrypted strings that are decrypted at run time. Jasypt can be integrated into the Spring configuration framework so that property values are decrypted as the configuration file is loaded.  Jasypt’s approach replaces the the property management technique with one that recognizes encrypted strings and decrypts them. This method uses password-based encryption, which means that the system still needs a secret password in order to decrypt our credentials. We don’t want to simply move the secret from one file to another, and Jasypt avoids that by passing the key as an environment variable or even directly to the application through a web interface each time it is deployed. </p>

<p>This ability is beneficial since it removes the need to embed plain-text credentials in configuration files, and allows the adopter to secure keep track of all encrypted settings in source control systems, safely sharing the build configuration with others. Sensitive pieces of data are only restricted to the deployment environment.</p>

<h2 id="user-driven-security-features">User-Driven Security Features</h2>
<p>The following features may be employed to afford some user control of the SSO experience.</p>

<h3 id="long-term-authentication">Long Term Authentication</h3>
<p>The long term authentication feature, commonly referred to as “Remember Me”, is selected (usually via checkbox) on the CAS login form to avoid reauthentication for an extended period of time. Long term authentication allows users to elect additional convenience at the expense of reduced security. The extent of reduced security is a function of the characteristics of the device used to establish a CAS SSO session. A long-term SSO session established from a device owned or operated by a single user is marginally less secure than a standard CAS SSO session. The only real concern would be the increased lifetime and resulting increased exposure of the CAS ticket-granting ticket. Establishing a long-term CAS SSO session from a shared device, on the other hand, may dramatically reduce security.
The likelihood of artifacts from previous SSO sessions affecting subsequent SSO sessions established by other users, even in the face of single sign-out, may increase the likelihood of impersonation. While there are no feasible mitigations for improving security of long-term SSO sessions on a shared device, educating users on the inherent risks may improve overall security.</p>

<p>It is important to note that forced authentication supercedes long term authentication, thus if a service were
configured for forced authentication, authentication would be required for service access even in the context of a
long-term session.</p>

<p>Long term authentication support must be explicitly enabled through
<a href="../installation/Configuring-Authentication-Components.html#long_term_authentication">configuration and UI customization</a>
during the installation process. Thus deployers choose to offer long-term authentication support, and when available
users may elect to use it via selection on the CAS login form.</p>

<h3 id="warn">Warn</h3>
<p>CAS supports optional notification of service access during an established SSO session. By default CAS
transparently requests tickets needed for service access and presents them to the target service for validation,
whereby upon successful validation access to the service is permitted. In most cases this happens nearly instantly
and the user is not aware of the CAS authentication process required to access CAS-enabled services. There may be
some security benefit to awareness of this process, and CAS supports a <em>warn</em> flag that may be selected by the user
on the CAS login screen to provide an interstitial notification page that is displayed prior to accessing a service.
By default the notification page offers the user an option to proceed with CAS authentication or abort by
navigating away from the target service.</p>

        </section>
      </div>

    <!-- FOOTER  -->
    <div id="footer_wrap" class="outer">
      <footer class="inner">
        <p>CAS is supported by the <a href="http://www.apereo.org/">Apereo Foundation</a>.</p>
      </footer>
    </div>
  </body>
</html>
